Columbia Kermit/kermit.zip/newsgroups/misc.20000217-20000824/[e-mail] _Fri Feb 18 02:10:07 2000.msg

Internet Message Format | 2020-01-01 | 9KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id CAA10169
    for <[e-mail]>; Fri, 18 Feb 2000 02:10:07 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id BAA20995
    for [e-mail]; Fri, 18 Feb 2000 01:53:31 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Jeffrey Altman)
Subject: Re: TELNET error with K95 1.19
Date: 18 Feb 2000 06:53:28 GMT
Organization: Columbia University
Message-ID: <88iq98$kg0$[e-mail]>
To: [e-mail]

In article <[e-mail]>, Joe Doupnik <[e-mail]> wrote:
:     Yup, that's the short answer. There could have been another approach
: to the difficulty which is a client offers Telnet Options but does not halt
: waiting for responses. In principle, it says in bold quotes, Options can
: occur at any time in the session, though the principle collides with what
: to do about text exchanged in the meanwhile. Isn't that correct Jeff?
: If it were correct then a regular Telnet client could offer Options and
: still make progress on non-Telnet servers. I wish my UnixWare Telnet were
: that way, but it isn't. This boils down to chickens, eggs, and should we
: wait to check for traffic before crossing the road, or some such muddle.
:     Joe D.


The reasons that Kermit 95 and C-Kermit no longer connect without
waiting for telnet option negotiations when using TELNET protocol
is clearly detailed in

 http://www.kermit-project.org/telnet.html

The problem is that people are used to the behavior of the BSD telnet
client which only negotiates telnet options on the port assigned to
"telnet/tcp" in the /etc/services file.  If any other port is
specified telnet options are not negotiated unless a '-' is used as a
prefix to the port number.

This is exactly the behavior that Kermit 95 and C-Kermit have for
the SET HOST command.  The SET HOST command defaults to

  SET HOST <host> <port> /DEFAULT

The TELNET command is a shortcut for

  SET HOST /CONNECT <host> <port> /TELNET

In other words, it means use TELNET protocol.  The /DEFAULT protocol
switch in SET HOST instructs Kermit to try to determine the protocol
to use based upon the port number.

   23 telnet
  513 rlogin
 1649 telnet
  443 ssl
  151 telnet after ssl is negotiated
  992 telnet after ssl is negotiated
  543 klogin
 2105 eklogin
   80 no protocol (http)

anything else is treated as an NVT without telnet negotiations.

It is extremely important for Kermit to wait for negotiations to
complete when using telnet protocol:

 . When performing authentication and encryption it is not safe
   to send any data until after the authentication and encryption
   is successful.  Even sending other telnet negotiations can be
   a security hole.  Therefore, this must be done up front.

 . Our experience has shown that many telnetd implementations do
   not wait for the terminal type negotiation to be completed
   before starting the 'login' process.  This has several negative
   side effects:

   - as the terminal type continues to change the screen dimensions
     and other characteristics of the terminal might force the login
     prompt off the screen

   - the login process and its subprocesses will configure the
     environment with a different terminal type than the one
     negotiated between the client and server.

 . Waiting for the responses to negotiation requests allows Kermit to
   enforce policies based upon the state of the connection.

 . If Kermit does not wait for negotiation responses there is
   a timing problem when Kermit does not enter CONNECT mode
   immediately.  This is most prevalent when writing scripts
   with the INPUT command.  The first several INPUT commands
   in a Kermit script being executed on a Telnet session become
   very unpredictable.  This is because the initial data flow
   is entirely telnet negotiations which require several round
   trip times to complete.  This can vary from several hundred
   milliseconds to tens of seconds depending on the connection.
   These timing issues should be transparent to the script.

When a telnet state machine is implemented as per RFCs 854, 855, and
1143 there are no problems with being agressive about negotiating
telnet options.  The problems occurs when the server does not correctly
implement the telnet state machine.

For instance, the BSD FTP server (ftpd) is a proper Telnet NVT as per
RFC 854.  It doesn't support any Telnet Options at all.  But it
processes all Telnet Commands with appropriate responses such as
rejecting all attempts to activate a telnet option by send DONT and
WONT commands as appropriate.

The real telnet servers for which this is a problem include:

  . AOS/VS II
  . IBM OS/2 Warp 4.0
  . Several third party Windows Telnet servers
  . Meridian's Telnet to LAT gateway for NT
  . One release of Compaq Tru64 Telnetd which has been fixed by
    a patch

The most common problem is a Telnet Server that does not respond
to options that it was not specificly programmed to handle.  But
some of the servers such as IBM OS/2 Warp 4.0 and Meridian's gateway
product respond to various WILL commands with DO but then never
negotiate the option.

The OS/2 case is interesting because the server responds DO AUTH
since it does support the AUTH option but since there are no
authentication DLLs installed (the OS/2 TCP/IP 1.2 product had
Kerberos 4 in it) it thinks it has nothing to do.

The Meridian case appears to be a privately implemented telnet option
which conflicts with an IANA assigned option number.

Since I am now on a roll talking about Telnet bugs.  Almost every
telnetd distributed based upon the BSD Telnet code contains an off
by one error which will result in the loss of the last byte of data
being lost if the read from network data buffer is filled.  This is
true of every Linux telnetd, the GNU Telnetd, the SRP telnetd,
the Kerberos telnetd, the Next, and BeOS telnetds.  This bug will
be fixed in the next Kerberos 5 telnetd and is currently fixed
in the START_TLS telnetd supported by Peter Runestig.

But back to the original point of this thread.  The question is
what is the definition of the 'TELNET' command in Kermit 95 and
C-Kermit.  Does it mean:

 . make a connection to the host and guess what protocol should
   be used (if any), or

 . make a connection to the host and use Telnet protocol.

Since Kermit 95 and C-Kermit have other commands such as

  RLOGIN <host>

to make a connection using LOGIN protocol it makes sense that the
TELNET command would make connections using TELNET protocol.

This is pure and simple a design choice by me.  It changes the
behavior from previous versions of C-Kermit and Kermit 95 when the
TELNET command is used instead of SET HOST.  The old behavior was a
side effect of the fact that TELNET was the only protocol Kermit
supported on TCP/IP was for a very long time.  When it became obvious
in release 5A(190) that we needed a method to provide for TCP/IP
connections without any higher level protocols in order to support
things such as 'modemd' on Linux, the method used to handle this was
an unsupportable hack.

C-Kermit 7.0 and Kermit 95 1.1.19 incorporates a completely new design
for protocol handling that is general purpose.  Kermit now easily
handles TELNET, RLOGIN, KLOGIN, EKLOGIN, SSL, TLS, HTTP, RAW TCP/IP
sockets, and it is ready for FTP, SSH and any other protocols we
decide to add at a later date.  The Telnet state machine is completely
modular and supports both client and server side negotiations in a
single code base.  The only things the new Telnet code does not do
that I wish it did are:

 . Telnet Linemode
 . Telnet Speed
 . Telnet Remote Flow Control
 . Telnet 3270
 . Telnet Extended 3270
 . Telnet 5250
 . Telnet Remote Com Port Control (set speed, parity, flow control
   of remote serial port devices such as found on reverse terminal
   servers)
 . Send Go Aheads when Suppress Go Aheads has not been negotiated
   (this is the one violation of the Telnet protocol that I am
   aware of in C-Kermit 7.0 and Kermit 95 1.1.19)

I will get to implementing all of this as the need arises.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [e-mail]